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1.  Overview 

The  contract  begm  September  28, 1989  and  will  terminate  September  27, 1994.  A  no-cost  extenskm  has  been  requested. 
Ifthis  is  granted,  the  tnmination  date  will  be  extended  and  the  final  lepcKt  will  be  moved  to  a  later  date.  If  not,  this  draft  will  serve 
as  a  basis  for  comi^eting  the  final  report. 

The  contract  began  with  seven  tasks;  (1)  Digital  Emulation  Facility,  (2)  FPA  Seeker  Emulator  Development,  (3)  Special 
Studies,  (4)  Scrftware  Development,  (S)  Automated  Input,  (6)  PFP  Techndogy,  and  (7)  GN&C  Processor  Devek^tmenL  These 
tasks  were  developed  through  the  first  two  years  of  the  contract  when  virtually  all  funding  was  removed.  Two  Annual  reports, 
consisting  of  7  volumes  each,  report  on  the  technical  work  during  these  two  years  [1,23,4,5.6,7.8.9,10.11,12,13,14].  These  re¬ 
ports  were  delivered  to  USASSDC  as  AR-0142-90-001  and  AR-0142-91-002.  Each  volume  in  each  year,  corresponds  to  one 
of  the  tasks.  No  additional  reporting  on  these  tasks  will  be  presented  in  this  rep(M^ 

Two  additional  tasks  have  been  developed  since  the  funding  cut.  The  first  was  a  q)eed  test  on  the  rad-hard  FPU  chip  devel¬ 
oped  by  Harris.  A  summary  of  this  testing  and  the  associated  report  is  given  in  Section  2.  More  detail  is  available  in  the  Special 
Technical  Repext.  STR-0142-93-01S  [IS]. 

The  second  task  is  the  development  of  an  FPA  Tbst  System.  This  task  is  in  i»ogress  and  is  scheduled  to  complete  on  Sept 
27, 1S194.  However,  if  the  contract  is  extended,  the  completion  date  will  be  pushed  out  approximately  two  months  on  the  first 
system  and  another  month  on  the  second  system.  It  will  be  quite  difficult  to  complete  these  systems  on  the  specified  due  date, 
^tkm  3  gives  a  status  report  on  the  FPA  Test  System.  Additional  Special  Technical  Reports  will  be  available  after  the  hardware 
is  delivered  if  the  contract  is  extended. 

2.  Rad  Hard  FPU  Chip  Testing 

Georgia  Tech  gotthreehardenedchq>sfiromHarris;FPU#l,FPU#2andFPU#3.  Only  two  chips  were  tested-47U#l  and 
FPU#2.  The  third  ch^  (FPU#3)  gave  erroneous  results  at  any  frequency.  This  may  have  been  caused  by  inserting  the  chip  into 
the  socket  incorrectly  due  to  an  incorrea  pin  diagram.  The  second  chip  (FPU#2)  was  also  inserted  into  the  socket  incorrectly. 
However,  it  did  not  stay  in  that  configuration  fix  verylong  and  the  only  damage  was  a  disabling  of  the  fourth  bit  on  the  chip  output 
This  was  remedied  by  modifying  the  test  software  to  mask  out  that  bit  A  commercial  version  of  the  ITU  was  also  tested  for  com¬ 
parison  purposes.  The  test  results  follow. 

2.1.  Rad  Hard  Chips 

Geoigia  Tech  received  three  rad-hard  chips  from  Harris  which  were  labeled  FPU  #  1 ,  FPU  #2,  and  FPU  #3.  In  the  process 
of  building  the  FPU  test  board  there  was  an  error  in  the  pin-out  information  sent  to  Georgia  Tech  from  Harris.  Chip  lead  214  was 
designated  as  a  "no  connection”  on  the  pin-out  Georgia  Tech  grounded  all  the  pins  which  were  so  marked.  When  the  chip  was 
inserted  into  the  socket  the  lead  on  this  pin  melted.  After  getting  a  second  pin-out  listing  from  Harry  Diamond  Laboratories  it 
was  found  that  this  lead  is  tied  to  Vcc.  ^tpre^xiate  changes  were  made  on  the  board  to  correct  this  problem.  This  chip,  FPU  #3, 
would  not  give  correct  results  at  any  frequency  and  was  discartfed.  FPU  #2  had  a  suick  bit  on  the  FPU  ouqrut,  bit  4.  However 
the  chip  furtedoned  correctly,  so  the  software  test  was  modified  to  ignore  this  bit  The  speed  tests  were  run  using  the  same  tests 
without  checking  this  particular  ouqmt  bit  It  is  possible  that  the  results  could  be  too  high  for  any  of  the  tests  on  this  chip.  This 
could  luqrpen  if  this  particular  bit  was  in  error,  but  no  other  bit  in  the  output  was  in  error.  For  this  case,  we  would  accept  the  output 
ascorrecL  FPU#1  was  neverusedinany  of  thepreliminary  testing.  It  was  only  inserted  into  the  test  board  after  all  the  debugging 
had  been  completed  and  the  other  rad-h^  chip  was  running  correctly.  FPU#1  is  somewhat  faster  than  FPU  #2  on  virtually  every 
lest  and  voltage  condition. 


Ihble  1.  COMMERCIAI-RAD  HARD  FPU  TEST 
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**  The  value  was  below  10  Mhz  and  could  not  be  tested  with  the  available  clock. 


Zl.  Test  Results 

TheiestfesultsaieshowninTiblelfortheconunerciaIchip(Coin)andtwooftheiad-hardchips(#l,#2).  The  commercial 
chip  was  designed  on  the  Genesil  Silicon  Compiler  and  fabricated  by  NCR  using  their  125  micron  CMOS  process.  This  chip 
was  one  of  the  early  designs  and  did  not  use  some  of  the  primitives  that  were  available  for  later  designs.  Thedesign  wasprojected 
to  run  ar  6.6  Mhz.  according  to  the  Genesil  timing  simulator. 

The  rad-hard  FPU  chq)s  were  designed  using  a  new  version  of  the  Genesil  silicon  compiler.  Harris  Ctuporation,  with  the 
help  of  Silicon  Compiler  Systems  Corp.,  built  a  rad-hard  version  of  the  Genesil  compiler.  This  compiler  implemented  some  of 
the  primitives  in  the  commercial  comi^er  using  the  Harris  CMOS/SOS  1.2S  micron  process  as  the  target  foundry.  Thehardened 
chips,  in  a  iK»-4K:tive  mode,  use  about  half  the  power  of  the  commercial  FPU  chip.  During  testing  with  S  volts  relied  to  each 
chip,  the  hudened  FPU  used  around  100  milliainp.  of  current  compared  to  200  milliamp.  for  the  commercial  chip.  Under  test 
the  commercial  chip  did  not  change  in  current  consumption,  but  the  rad-hard  chip  incroised  to  300  milliamps. 

Ibsts  were  separated  into  10  specific  categories.  These  are  indicated  as  (1 )  logical ,  (2)  shift,  (3)  integer  addition,  (4)  integer 
mult^lkation,  (S)  floating  point  addition,  (6)  floating  point  multiplication,  (7)  pack  exponent  and  float,  (8)  generate  seed,  unpack 
erqronent,  unpack  mantissa,  square  toot  expoitent,  and  square  root  mantissa,  (9)  round  or  truncate  a  result,  and  (10)  sign  manipula¬ 
tion.  The  commercial  chip  p^otms  faster  than  the  rad-hard  version.  The  two  hardened  FPU  chips  produced  q)eed  characteris¬ 
tics  that  differed  greatly.  This  could  be  due  to  fabrication  quality  variations  from  die  to  die,  or  the  way  the  chips  were  selected 
for  sending  to  Georgia  Ibch.  To  establish  more  rigid  comparisons  it  will  be  necessary  to  quantify  several  of  the  cmmercial  chips 
as  well  as  the  rad-hard  versions.  However,  this  test  does  give  a  sense  of  the  rad-hard  performance  relative  to  commercial  CMOS 
performance. 

3.  FPA  Test  System 

3.1.  Design  Overview 

The  Georgia  Tech  FPA  test  system  is  being  developed  to  atalyze  the  characteristics  and  quality  of  an  FPA  sensor.  It  also 
allows  a  user  to  study  the  effectiveness  of  the  FPA  sensor  when  using  various  signal  and  image  processing  functions.  The  primary 
features  siqtported  by  the  Georgia  Tech  system  are  the  ability  to: 

(1)  interface  a  wide  range  of  FPAs  using  a  specification  defined  by  USASSDC, 

(2)  display  the  raw  FPA  image  live  on  a  color  monitor  to  enable  a  user  to  visually  locate  bad  detectors,  and  to  compare  and  charac¬ 
terize  the  quality  of  an  FPA  sensor, 

(3)  select  or  program  any  of  the  four  signalrimage  filters  provided  (non-uniftninity  compensation,  temporal  filtering,  ^tial  fil¬ 
tering,  md  threshtdding),  and 

(4)  disiday  the  intermediate  Altered  frame  ouqwts  in  real  time,  id  a  refresh  rate  that  does  not  strain  the  eyes(minimum  ISscieen 
updates  per  second). 

The  system  is  designed  to  support  FPA  Frame  sizes  up  to  1024  x  1024  with  real-time  display  of  any  128  x  128  or  2S6  x 
256  segment  System  development  invedves  hardware  and  software.  The  hardware  consists  of  four  board  designs  (see  Figure 
NO  TAG),  Cr-iw  (SBus  Interface  Board),  GT-FSPB  {FPA  Signal  Processor  Board),  GT-FIM  {FPA  Interface  Module),  and 
GT-FFE  {FPA  Frame  Emulator).  The  sOffimt  consists  of  a  grajAical  user  interface  (GUI).  GT-XSPJ  (Y  Windows-based  Signal 
Processing  Interface),  designed  to  run  on  a  SUN  SPARC  platform.  The  SPARCstatkm  20  Model  50  SX  with  a  1 7”,  1 1 52x900 
resolution,  24-bit  color  monitor  has  been  chosen  as  the  host  platfcnm  for  the  Geoigia  Tech  FPA  test  system. 

The  GT-SIB  interfaces  the  SPARCstation  20  SBus  port  with  the  GT-FSPB.  It  plugs  into  one  of  the  SBus  connectors  inside 
the  SPARCstiaion  20  CPU  box.  A  custom  connector  is  provided  at  the  back  of  the  box  for  connection  to  an  external  chassis  (via 
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Figure  1.  Georgia  Tech  FPA  Test  System  Hardware 

a  short  cable)  containing  the  GT-^PB,  GT-PIM,  and  GT-47E.  The  external  chassis  contains  its  own  power  supply  and  fan. 
The  GT-FSra  is  die  hardware  core  of  the  GT  FPA  Test  System,  containing  the  Georgia  Tech  signal  {nocessing  (SP)  chip  set. 
To  accommodate  different  FPA  sensors,  the  FPA  interface  circuitry  is  implemented  on  a  modular,  interchangeable  daughter  board, 
GT-4TM.  An  extmnal  FPA  connector  is  used  to  connect  to  the  FPA’s  data  acquisition  system.  To  test  and  emulate  a  real  FPA 
sensor,  the  GT-FFE  is  used  to  generate  FPA  interface  signals  (Pixel.Data,  PixeLSync,  and  Frame.Sync)  that  exactly  men  or 
exceed  the  NRaD  FPA  interface  qiecifkadons. 

The  GT-XSPI  custom-designed  graphical  software  is  based  on  the  XView  and  MIT  X  Shared  Memory  Extension  grsqihics 
routines.  The  GT-XSPl  allows  a  user  to  amdyze,  in  real  time,  the  characteristics  of  an  FPA  sensor  and  the  effectiveness  of  each 
image  filtering  process  with  resgiect  to  the  sensor. 

3.2.  System  Development 

One  of  the  two  SPARCstation  20  woritstations  to  be  used  as  the  FPA  Test  System  host  has  just  arrived.  The  tolerating  sys¬ 
tem  (Solaris  2.3)  is  currently  being  installed.  The  other  SPARCstation  20  will  be  ordered  shtvtly.  The  following  sections  describe 
the  status  (rf  hardware  and  software  development. 


3J.1.  Hardware  Devdopment 

32.1.1.  GTSIB  (Georgia  Tech  SBus  Interface  Board) 

The  GT-SIB*s  hardware  design  and  components  have  been  specified.  Figure  2  shows  the  hardware  circuit  diagram.  It 
contains  an  SBus  DMA  Controller  chip  (LSI  Logic  L648S3A).  an  81^8  EPROM  (Microchip  27HC641)  for  storing  the  board's 
SBus  ID,  two  S-bit  r^teied  transceivers  (IDT  74PCT646)  for  16-bit  data  transfos,  two  8-bit  register^FFs  (IDT  74FCTS74) 
for  the  command  register,  several  EH^Ds  for  control^toface  logic,  and  an  external  connector  (around  SO  pins)  for  the  comiection 
toGT-FSPB. 

The  GT-SIB  reads  in  rtal  time  the  objea  features  and  pixel  intensities  of  raw/filtered  FPA  frames  from  the  GT-FSPB, 
which  then  transfers  this  real-dme  data  to  the  host  via  the  SBus.  Continuous  data  updates  are  made  possible  by  the  DMA  block 
chaining”  feature  of  the  L648S3  A.  The  maximum  data  size  ofsingle  real-time  updates  is  184320  bytes,  which  consists  of  16-bit 
pixel  intensities  of  five  128x128  frames  and  10-byte  object  features  (total  object  area,  total  object  intoisity,  X-  and  Y-coordinate 
ot  area  centroid,  X-  and  Y-coordinate  of  intensity  centroid)  of 4,096  objects.  The  L648S3  A  performs  DMA  transfers  at  a  maxi¬ 
mum  rate  of8.3  Mbytes/sec  on  a  2S-MHz  SBus.  This  bandwidth  gives  a  maximum  of4S  real-time  data  i^pdates  per  second  from 
the GT-^PB  to  the  host’s diqrlayntetnory.  Meeting  the  real-time  disfday  rate  at  the  host’s  monitor  (minimum  IS  screen  updates 
per  secrnid)  should  not  be  difficulL 

In  addition  to  reading  real-time  frameArbject  data,  the  host  can  perform  other  tasks  on  the  GT-FSPB  and  GT-FIM  by  writ- 
ing  the  pn^  command/instruction  to  the  GT-SIB  command  register.  The  complete  list  ofcommands  is  shown  in  Table  1,  which 
includes  initialization  and  diagnostics  of  the  Georgia  Tech  SP  chips,  initialization  of  GT-FIM’s  processing  mode,  setting  of  the 
Pixel-Address  Mtg),  and  system  reset  Note  that  all  data  transfers  occur  via  D16_Data[lS;0]  lines. 

Thble  1.  Command  Register 


Opcode 

13:0] 

Operand 

iii-oj 

Command  Description 

- 

No  operation  (idle  mode) 

0001 

Buffer_En[5K)] 

Real-time  frame/object  data  read  of  participating  buffers  specified  in 

Buffer_En[5:0]  =  FPA.EN,  NUC.EN,  TF_EN,  SF.EN,  THR.EN,  CTO.EN 

0010 

Host_Addr(5;01 

Write  to  GT-VNUC  chip  (calibration  data,  control  registers,  internal  busses,  etc.) 

0011 

Host_Addr[5:0] 

Read  from  GT-VNUC  chip  (calibration  data,  internal  buses,  self-test  data,  etc.) 

0100 

Host_Addr[7:0] 

Write  to  GT-VTF  chip  GIR  filter  coefficients,  control/test  instruction,  etc.) 

0101 

Host_Addrr7:0] 

Read  from  GT-VTF  chip  GH^  filter  coefficients,  internal  results,  self-test  data,  etc.) 

0110 

Host_Addrr7:0] 

Write  to  GT-VSF  chip  (filter  coefficients,  control/test  instruction,  etc.) 

0111 

Host_Addr[7:0] 

Read  from  GT-VSF  chip  (filter  coefficients,  internal  results,  self-test  data,  etc.) 

1000 

Host_Addr[3:0] 

Write  to  GT-VTHR  chip  (thresholding  mode,  coefficients,  etc.) 

1001 

Host_Addr[3:0] 

Read  from  GT-VTHR  chip  (control  register,  coefficienu,  internal  results,  etc.) 

1010 

- 

Sequential  write  to  PAM  memory 

1011 

- 

Sequential  read  from  PAM  memory  (used  during  memory  test) 

1100 

— 

Write  10  GT-FIM  control  register  where  D16  Data[9:0]  =  FIM  Control[9:0]  = 
TDI_sel[2:0]  (1/2/4/8/16),  Seg_size  (128x128/256x256),  Seg_Sel[5:0]  ((yi/..763) 

1101 

- 

RESERVED 

1110 

Write  synthetic  pixel  data  stream  to  GT-4riM  (connect  the  external  port  of  a  second 
GT-SIB  directly  to  the  FPA  port  of  GT-FIM,  D16_Data  »  Pixel_Data) 

nil 

- 

FPA  Test  system  reset 

32.12.  GT-FSPB  (Georgia  Tech  FPA  Signal  Processing  Board) 

The  GT-FSPB’s  hardware  design  and  components  have  been  q)eciried.  Rgure  3  shows  the  hardware  circuit  diagram. 
It  consists  of  the  Georgia  Tech  signal  processing  (SP)  chip  set  (total  7  ASICs),  sixteen  64Kx4  SRAM  chips  (Cyi»ess  CY7C192), 
eight  16Kx4  SRAM  chips  (Cypress  CY7C162),  nine  MKxl6  SRAM  modules  (Cypress  CYM1622),  two  line  drivers  GOT 
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Figure  2.  Georgia  Tech  SBus  Interface  Board  (GT-SIB) 

74FCT244)  for  opcode  and  qierand,  two  B-bit  registered  transceivers  (IDT  74FCT6t6)  for  16-bit  data  transfers,  several  EPLDs 
for  control  logic,  an  external  connector  to  the  GT-SIB,  and  a  daughter-board  connector  to  the  GT-FIM.  Note  that  each  frame/c^ 
ject  buffer  is  unfriemented  by  static  RAMs  with  separate  HO.  This  allows  a  buffer  to  be  read  by  the  host  for  real-time  display 
without  interrupting  the  writing  of  current  output  frame/object  data  by  the  SP  chip. 

Processing  will  be  done  on  128x128  frames  at  frame  rates  up  to  1(X)  fps.  If  the  FPA  has  a  larger  frame  size  (up  to  1024x 1024 
frame  size  is  suppwted),  processing  will  be  done  on  a  selected  part  of  the  FPA  (called  a  frame  segment)  which  is  128x128  in  size. 
This  will  keq>  the  processing  rates  consistent  widi  the  signal  processing  chip  set  Since  the  NUC and  TFchipscan  handle  128x128 
and  2S6x2S6  frame  sizes,  a  second  processing  mode  with  256x256  frame  segments  will  be  included.  For  a  256x256  FPA  sensor, 
SF,  THR,  CLS,  and  CTR  chips  will  be  disabled  and  only  NUC  and  TF  will  be  in  the  processing  chain.  This  will  provide  full 
256x256  processing  of  these  frames  at  a  reduced  frame  rate  (the  rate  will  be  around  25  Hz).  The  other  SP  chips  were  built  with 
internal  memory  elements  that  prohibit  them  from  being  used  on  these  larger  frame  sizes. 

32.13.  GT-FIM  (Georgia  Tech  FPA  Interface  Module) 

The  GT-FIM’s  hardware  design  and  components  have  been  q^ecified.  Figure  4  shows  the  hardware  circuit  diagram.  It 
consists  of  a  Xilinx  XC40(X)  FPGA  to  implement  the  TDI  and  control  logic  circuitry,  four  lMx9  SRAM  modules  (Cyiness 
C YM 1 560)  fw  the  1024x 1024  input  frame  buffers,  and  three  64Kx  1 6  SRAM  modules  (Cypress  C YM 1 622)  for  the  pixel-address 
nu^)  and  256x256 running  sum  memories,  six  8-bit  DFFs/registers  for  various  pixel  and  control  registers,  a  connectcM'  to  the  GT- 
FSPB  motherboard,  and  a40-pin  connector  for  connection  to  the  NRaD  FPA  dioa  acquisition  system.  The  FPA  interface  signals 
(Pixe]_Data.  Pixel_Sync,  and  Frame.SyiK)  are  described  further  in  Section  3.3. 

The  GT-FIM  supports  several  processing  modes  based  on  the  control  register  configuration  (TDI_sel[2:0],  Seg_size,  and 
Seg_seI[S:0]).  Hve  TDI  (Hme  Delay  and  Integration)  factors  can  be  selected:  1,2, 4,8,  and  16  (number  of  frames  that  are  time- 
avnagetQ.  'IVoframes^mentsizesaresupportBd,128xl28and256  x  256.  The  segment  location  to  be  nKMiitored  in  the  overall 
FPA  frame  is  user  programmable.  Another  useful  feature  supported  by  the  GT-FIM  is  the  mqjping  of  a  random  pixel-input-order 
onto  the  raster-scan  pixel  stream.  This  is  done  by  the  Pixel-Address  Map  (PAM)  memmy,  which  is  loadable  from  the  host 

During  the  initial  system  test  when  we  are  not  using  a  real  FPA  sensor,  we  will  simulate  the  input  FPA  image  by  connecting 
the  GT-FIM’s  FPA  connector  to  a  second  GT-SIB.  This  allows  the  host  to  generate  the  input  FPA  frames  synthetically  and  send 
the  pixel  stream  to  the  Georgia  Tech  FPA  Test  System,  via  the  SBus  connection  at  the  second  GT-SIB. 

32.1.4.  GT-FFE  (FPA  Frame  Emulator) 

There  are  two  methods  for  testing  the  Georgia  Tech  FPA  Test  System.  The  first  method  is  to  use  a  second  SBus  Interface 
Board  (GT-SIB)  to  stream  in  synthetic  pixel  data  on  the  SBus.  The  maximum  pixel  burst  rate  is  6.67  MHz  (150  ns  per  pixel), 
which  is  below  the  20  MHz  bum  rate  qiecification.  However,  scene  data  with  very  large  numbers  of  frames  can  be  generated 
and  straed  on  the  SPARCstation  20  host  The  advantage  to  this  method  is  flexibility.  The  user  can  play  the  scene  data  through 
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the  GeofRia  Ikch  signal  ptocessing  chip  set  and  investigate  the  effectiveness  of  algorithms.  The  disadvantage  is  that  this  method 
does  not  test  the  real-time  capability  of  the  system. 

The  second  method  is  to  build  an  FPA  Frame  Emulatcx  (GT-FFE)  board  which  wiU  be  mounted  in  the  external  chassis 
with  GT-^’SPB  and  GT-^TM.  The  GT-FFE  wiO  generate  all  die  control  signals  and  pixel  data  as  though  it  were  the  FPA  sensor 
system.  The  signals  (Frame.Sync,  Pixel_Sync,  PixeLDaia[lS.‘0])  will  be  sent  out  on  a  connector  through  a  ribbon  cdile  back 
into  the  GT-FIM  input  connecttx^  port  The  frame  buffer  in  GT-4^  can  store  up  to  32. 128x128, 16-bit  frames  of^ta  or  eight 
256x256  frames.  A  counter  will  tensed  to  return  to  the  first  frame  when  the  last  frame  is  sent  The  pixel  burst  rate  is  20  MHz 
(one  pixel  data  every  50  ns)  with  a  pause  option  between  tows  and  frames.  This  would  lest  the  real-time  performance  of  the  Geor¬ 
gia  Tech  FPA  Test  Syston  using  the  NRid)  input  specifications. 
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Figure  4.  Georgia  Tech  FPA  Interface  Module  (GT-FIM) 


Figure  NO  TAG  shows  the  hardware  circuit  diagram  of  GT-FFE.  It  consists  of  128, 16Kx4  SRAM  chips  (IDT71S>82), 
sixteen  bidirectional  data  transceivers  (IDT  74PCT24S),  nineteen  DFFs^gisters  (IDT  74FCTS74),  two  S-Int  registered  vans* 
ceivers  (IDT  74PCT646),  and  En.Ds  for  the  control  logic.  The  buffering  of  SRAM  data  and  address  signals  is  necessary  to  reduce 
capacitive  loading  and  excessive  [xapagation  delays. 

3  J  Software  Design 

The  GT-XSPI  graphical  user  interface  (GUI)  design  is  shown  in  Figures  6.  The  GUI  gives  a  user  control  on  the  mode 
and  diq}lay  selection  of  the  FPA  input  and  SP  outputs.  It  allows  the  user  to  analyze,  in  real  time,  the  characteristics  of  an  FPA 
sensOT  and  the  effectiveness  of  each  image  filtering  process  with  respect  to  the  sensor.  Some  changes  have  been  made  since  the 
last  rqx)rt  was  written.  They  provide  a  better  user  interface  and  conform  to  SUN’sxWew  library  rouunes.  Additional  improve- 
ments  are  possible  during  the  course  of  implementing  the  interface.  The  firmware  (SBus  driver)  between  GT-XSPl  and  the  GT 
FPA  Test  System  hardware  will  be  develtqwd  next 

Rgure  6  shows  the  screen/cockpit  layout  Up  to  five  real-time  Display  Windows  can  be  activated  by  the  user.  The  user 
can  choose  the  Disfday  Window  size  at  integer  multiples  of  128x128,  from  25^56  to  640x640)  and  position  it  anywhere  on  the 
screen.  Area  and  intensity  centimds  are  displayed  in  ’’-t-”  and  "x”  shapes,  overlaying  the  image  of  the  selected  Display  Window(s). 

Figure  7  shows  the  main  command  menu.  A  click  on  each  button  except  ’’Halt” and  ”(^t”  will  bring  iq>  its  correqxmding 
contrtd  panel  as  shown  in  Hgure  8  and  9.  The  size  of  each  real-time  Display  Window  can  be  resized  to  either  256x236, 384x384, 
5 12x5 12  or 640x640.  Thoe  are  five  Display  Windows  (FPA,  Non-Uniformity  Compensation,  Temporal  Rlter,  Spatial  Filter  and 
Thresholding)  and  each  of  them  can  be  resized  independently.  A  resizing  request  is  made  using  the  Main  Option  Panel  in  the  Main 
Control  Panel  (Figure  8). 

Besides  window  resizing,  oth«'  standard  windowing  features  such  as  zoom,  close,  and  pan  on  a  zoomed  image  are  pro¬ 
vided.  There  are  two  ways  (rfzooming.  Oneismenudrivenzoomingor”incrementalzooming”,andtheotherisnKMisecontrolled 
zooming  or  "arbitrary  zooming”  The  incremental  zooming  lets  the  user  zoom  inAxit  by  selecting  an  rqrproiHiate  button  in  the  zoom 
menu  of  the  di^lay  window.  Thearbitraryzoomingletstheuserzoominonaqrecificixxelofinterestquickly.  As  the  user  presses 
the  middle  button  of  the  mouse  and  drags  the  mouse,  a  rectangultu  box  spears.  Whm  the  user  relea^  the  button,  the  zooming 
operation  is  initiated  and  the  Display  Vfindow  disidays  the  pixels  inside  the  bounding  box.  This  operation  can  be  enabled/disabled 


SRAM_CB13^1 


V - y - ^  SPbus 

Connect  to  FPA  connector  at  GT-^ETM  (continued  from  GT-FSPB) 


Figure  5.  FPA  Frame  Emulator  (GT-FFE) 

through  the  Option  Control  Panel  (Figure  9).  There  are  two  ways  of  panning.  The  user  can  pan  the  zoomed  image  either  using 
arrow  keys  on  a  keyboard  or  mouse  clicking  on  the  pan  window.  By  pressing  the  left-arrow  key,  the  region  being  displayed  in 
the  Display  >^iu]ow  shifts  one  FPA  pixel  to  the  left,  by  pressing  the  up-arrow  key,  it  shifts  one  FPA  pixel  up,  and  so  on.  By  clicking 
the  mouse  in  the  pan  window,  the  displayed  region  shifts  to  where  the  mouse  points  to.  By  combining  these  two  panning  opera¬ 
tions,  the  user  can  pan  to  the  pixel  interest  easily  and  precisely.  Finally,  a  user  wants  to  monitor  the  pixel  intensity  while 
moving  the  cursor,  the  Pixel  ^ue  Window  can  be  activated. 

The  GUI  features  provided  allow  a  user  to  visually  locate  bad  FPA  detectors.  The  various  Display  Mndows  of  filtered 
FPA  images  also  allow  a  user  to  characterize  the  strengths  and  weaknesses  of  a  particular  FPA  sensor  with  respect  to  color  band, 
types  of  noise,  background,  etc.  A  user  can  visually  compare  the  effects  of  non-unifOTmity  compensation,  tempcxal  Filtering, 
spatial  filtering,  and  thresholding.  The  Program  button  allows  a  user  to  program  the  SP  filter  chips  (NUC,  TF.  SF,  and  THR). 
The  Program  Panel  example  for  the  Spatial  Filtering  chip  is  shown  in  Figure  9.  If  certain  effects  are  not  desirable,  the  user  can 
re-program  the  filter  chips.  For  example,  a  user  can  experiment  with  different  thresholding  modes  (simple,  adjusted,  additive) 
in  the  Thresholding  ch^.  Note  that  the  FPA  Program  I^el  initializes  parameters  specific  to  the  FPA  sensor  being  tested,  such 
as  gain,  offset,  frame  segment  size  (128x128  or  256x256),  selected  frame  segment,  pixel-address  mapping  (how  the  pixel  data 
streams  out),  TDI  factor  (divide  by  1, 2, 4, 8,  or  16).  and  input  source  (real  FPA  sensor  or  host’s  synthetic  FPA  input  image). 

The  Centroiding  Control  Panel  has  a  different  appearance  from  other  control  panels  associated  with  filter  chips,  since  it 
does  not  possesses  its  own  image  di^lay  (Figure  1 0).  The  panel  enables/disables  overlay  di^lay  of  both  area  and  intensity  cen¬ 
troids  on  each  display  image  sqxirately. 
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Figure  6.  GT-XSPI  Graphical  User  Interface 


Main  Control  Panel 

rmA)rNUC)riD(  SF  )CTOR^rCNf)(Option)(  Hall)(  Quit) 


Description: 

FPA  Button  p(^  up  FPA  Control  Panel  (controls  raw  Focal  Plane  Array  modes  &  display) 

NUC  Button  pc^  up  NUC  Control  Panel  (controls  Non-Unif(»inity  Compensation  chip  &  di^lay) 
TF  Button  pc^  up  TF  Control  Panel  (controls  Temporal  Filtering  chip  &  display) 

SF  Button  pops  tg)  SF  Control  Panel  (controls  Spatial  Filtering  chip  &  display) 

THR  Button  pc^  up  THR  Control  P^l  (controls  Thresholding  chip  &  display) 

CNT  Button  pops  up  Centroid  Control  Panel  (controls  Centroiding  t^lay) 

Option  Button  ptqts  up  Main  Option  Panel  (controls  various  t^ons  of  the  interface) 

Halt  Button  stops  updating  all  the  disf^y  windows. 

Quit  Button  terminates  the  program. 

Figure  7.  GT-XSPI  Main  Control  Panel 


3.3.  FPA  Interface  Speciflcations 

Georgia  Tech  contacted  Mr.  Steve  Frisbie  at  NRaD  to  clarify  few  things  related  to  the  interface  between  the  NRaD  FPA 
data  acquisition  system  and  the  Georgia  Tbch  FPA  Test  System.  The  following  is  a  summary  of  the  FPA  interface  iqtecifications 
based  on  our  conversation  with  Mr.  Steve  Frisbie  on  April  19, 1994. 
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Figure  8.  Main  Option  Panel:  Size  Option  for  each  Display  Window 

NRaD  cunently  uses  a  40-pin  ribbon  cable  for  the  FPA  digital  interface  signals.  The  interface  signals  are  Frame.Sync, 
Pixel_Sync,  and  Pixel_Data[lS:0].  The  Pixel_Data[15:0]  is  a  16-bit  2’s  complement  pixel  intensity,  which  is  the  output  of  a 
12-bit  A/D  converter  and  sign-extended  to  16  bits.  The  rising  edge  of  Pixel.Sync  indicates  when  Pixel.Data  can  be  latched  in 
(seeFigure  11).  It  is  assumed  that  Pixel.Data  is  stable  20  ns  prior  to  th(  rising  edge  of  Pixel_Sync,  and  no  longer  driven  afterward. 
Signal  values  might  hold  longer  than  0  ns  due  to  the  "relatively  slow”  discharge  of  the  load  c^acitance.  The  skew  problem  be¬ 
tween  the  FPA  Data  Acquisition  System  (cable  input)  and  the  FPA  connector  at  the  GT-FIM  (cable  output)  should  not  present 
a  problem  if  the  skews/delays  at  the  cable  output  side  of  Pixel_Sync  and  Pixel_Data  are  relatively  even.  Note  that  a  1 2-ns  skew 
is  possible  if  a  6-foot  cable  is  used,  assuming  a  2-ns  propagation  delay  per  foot  of  cable. 

Pixels  are  not  sent  at  a  fixed  rate,  but  in  a  "burst  and  idle”  manner.  The  maximum  burst  speed  from  NRaD’s  FPA  electronics 
is  yet  to  be  confirmed,  but  the  CT-FIM  is  designrd  to  support  a  burst  speed  of  20  MHz  (SO-ns  minimum  burst  period)  which  is 
more  than  sufficient.  The  pixels  are  also  not  sent  in  a  raster-scan  order.  Different  FPA  vendors  have  different  pixel  output  se¬ 
quences.  To  accomodate  this,  the  GT-FIM  is  designed  to  handle  total  random  ordering,  by  re-mapping  each  pixel-output-se¬ 
quence  number  with  its  actual  pixel  address/location  (user  programmable  by  the  GT-FIM  Pixel-Address  Map  memory). 

The  pin  description  at  the  40-pin  FPA  connector  is  as  follows:  (to  be  confirmed) 

GND:  all  odd  pin  numbers  1 , 3,  S. ... ,  39 

Pixel_DataO ...  Pixel_Datal5:  even  pin  numbers  0, 2, 4, ...,  30 

PixcLSync:  pin  32 

Fiame_Sync:  pin  34 

unused  pins:  36,38,40. 

The  external  cable  used  is  a  lOO-Ohm  ribbon  cable  (planned  to  be  replaced  by  a  twisted  pair  cable)  approximately  6  feet  long. 
The  signal  pins  must  be  terminated  at  the  receiving  end  (at  GT-FIM).  The  line  termination  method  is  being  investigated. 

The  Pixel.Data  is  not  always  the  true  pixel  intensity  from  the  FPA  sensor,  since  it  can  be  adjusted  by  the  user  with  a  gain 
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Figure  9.  Control  Panel  for  FPA,  NUC,  TF,  SF  and  THR  Display  Windows 
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Figure  11.  FPA  Interface  Signal  Timing  Diagram 
and  offset  in  the  FPA  data  acquisition  system: 

Pixel_Data  *  (FPA jpixeljnt  —  Offset)* Gain .  (1) 

This  adjustment  must  be  "reversed/corrected”  at  the  GT  FPA  Test  System  to  get  the  tnie  pixel  intensity,  which  can  be  done  by 
the  Non-Uniformity  Compensation  chip  (GT-VNUQ  as  described  in  next  section. 

3.4.  Gain  &  Offset  Correction 
3.4.1.  NRaD  Test  System 

The  laboratory  data  acquisition  system  at  NRaD  is  constructed  with  the  dataflow  shown  in  Figure  12.  The  FPA  under  test 
is  irradiated  with  some  intensity.  A  single  pixel  will  be  subject  to  intensity/,-,  and  will  produce  an  ouq>utG,-.  This  ouqxit  can  then 
be  added  to  an  Offset  voltage,  GS,  and  mult^lied  by  a  Gain,  AT.  The  analog  value  is  thm  converted  to  a  twos  complement,  16-bit 
integer  and  sent  to  the  Georgia  Tech  FPA  Tl^  System.  The  Offset  and  Gain  are  used  to  expand  the  ouqmt  scale  to  cover  the  full 
range  of  the  A/D  converter.  IVro  typical  linearbxd  responses  are  shown  in  Figure  11.  Curve  A  represents  the  FPA  ouqxit,  Oi, 
Curve  B  represents  the  ouqxit,  0^  after  offset  and  gain  have  been  applied.  This  section  explains  the  way  these  signals  will  be 
processed  to  correct  for  gain  and  offset 

3.4  J.  Georgia  Tech  FTA  Test  System 

The  Georgia  Tech  FPA  Test  System  includes  a  Non-Uniformity  Compensation  (NUQ  chip  which  can  nuxlel  each  pixel 
response  as  a  set  of  four  line  segments,  which  are  continuous  and  monotonic^y  increasing.  It  should  also  be  noted  that  the  chqi 
can  model  each  pixel  using  1,2,  or  3  line  segments  if  the  user  chooses  to  do  so.  The  following  discussion  assumes  four  line  seg¬ 
ments  are  used,  but  rqiplies  to  all  cases.  The  line  segments  are  determined  by  using  five  known  intensities, //.  4.  /y .  andli. 
and  reading  the  pixel  reqxxises,  Oq,  O1.O2, 03,and04.  for  each  input  The  input-ouqiut  pairs  are  stored  in  the  memory  which 
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figure  12.  NRaD  Laboratory  Test  Sjvten 

supports  the  NUC  chip.  When  an  unknown  FPA  pixel  output.  Ox,  is  applied  to  the  NUC  chip,  the  ouQMit  of  the  chip  is  the  input 
pixel  intensity  as  specified  by  one  of  the  line  segments.  The  chip  first  determines  the  line  segment  by  searching  the  list  of  outputs 
until,  Oi  s  Ox  ^  Oi>7.  The  intensity  value  is  then  determined  from  the  equation. 


(2) 


where  i  =  0, 1, 2,  or  3. 

Since  the  signed  value,  Ota,  contains  OS  and  K,  the  calibration  data  will  automatically  include  these  values  as  part  of  the 
line  segment  definitions.  Thus,  the  NUC  chip,  when  calitvated  with  the  offset  and  gain  inputs  set  to  their  i»oper  values.  wiU  re¬ 
move  the  gain  and  offset  and  produce  the  correct  input  as  represented  by  an  approximation  of  Une  segments. 

3.4  J.  Special  Cases 

There  are  two  conditions  that  produce  qtecial  cases.  If  the  input, /;,  exceeds  some  level,  the  output,  will  saturate.  How¬ 

ever,  the  A/D  ouqxit  may  saturate  prior  to  this  level.  Hence  there  is  some  maximum.  Omax,  that  limits  the  ouq>ut  for/, 

As  shown  in  Figure  13  neither  A  nor  B  has  saturated  from  the  input  /;,  but  the  output  is  limited  by  the  A/D.  Thus  Oia  and  O^  are 
not  equal  for  the  case  shown  in  Figure  13  when  the  input  exceeds  the  value  which  produces  Omax, 


A  second  condition  exists  when  the  input  is  negative  as  shown  in  curve  B  of  Figure  13.  For/,- less  than  some  value, /mM. 
the  output  Oia  will  be  negative.  This  value  will  be  converted  into  an  equivalent  negative  digital  value,  Oid-  However,  the  NUC 
chip  does  not  recognize  negative  values  as  legal  inputs  and  will  convert  these  values  to  zero.  This  raises  the  question  of  how  these 
values  are  to  be  treated. 

3.4.4.  Design  Methodology 

The  current  plan  is  to  input  all  values  Oid  to  the  NUC  chip  and  use  the  chip  to  remove  the  gain  and  offsM  ^lied  by  the 
data  acquisition  system.  This  implies  that  all  negative  values  will  be  set  to  zero,  and  all  values  greater  than  Omax  will  be  set  to 
Omax.  This  also  implies  that  the  I^C  chip  has  to  be  calibrated  with  the  appropriate  Off'set  and  Gain  parameters  set  to  the  values 
that  will  be  used  during  the  test  If  the  cidibration  is  carried  out  for  one  set  of  Offset  and  Gain  values  and  a  new  setting  is  used 
during  the  test,  it  will  be  necessary  to  correct  all  the  values  in  the  NUC  chip  memory.  This  can  be  done  but  it  is  not  the  preferred 


mode  rf  ope«k»  In  aU  CMCS.  ihe  vilue  0«  is  in«fc  aviilabte  for  dMptay  and  <»  be  cimi^ 

pueL  However,  this  value  of  the  output  does  have  the  data  acquisition  system  oSiKt  and  gain  embedded  in  ihe  value. 
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